home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-dns-idpr-02.txt < prev    next >
Text File  |  1993-10-26  |  8KB  |  223 lines
  1.  
  2. Network Working Group                                         R. Austein
  3. INTERNET-DRAFT                           Epilogue Technology Corporation
  4.                                                             October 1993
  5.  
  6.  
  7.                           DNS Support for IDPR
  8.                       [draft-ietf-dns-idpr-02.txt]
  9.  
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet Draft.  Internet Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its Areas,
  15.    and its Working Groups.  Note that other groups may also distribute
  16.    working documents as Internet Drafts.
  17.  
  18.    Internet Drafts are draft documents valid for a maximum of six
  19.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  20.    other documents at any time.  It is not appropriate to use Internet
  21.    Drafts as reference material or to cite them other than as a "working
  22.    draft" or "work in progress."  Please check the 1id-abstracts.txt
  23.    listing contained in the internet-drafts Shadow Directories on
  24.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
  25.    munnari.oz.au to learn the current status of any Internet Draft.
  26.  
  27.    This is a working document only, it should neither be cited nor
  28.    quoted in any formal document.
  29.  
  30.    This document will expire before 27 April 1994.
  31.  
  32.    Distribution of this document is unlimited.
  33.  
  34.    Please send comments to the author.
  35.  
  36. 1. Introduction
  37.  
  38.    This note documents the support needed from the Domain Name System
  39.    (DNS) by Inter-Domain Policy Routing (IDPR).  The DNS changes are
  40.    minor and can be deployed with minimal impact on the installed DNS
  41.    community.
  42.  
  43.    When an IDPR Policy Gateway receives an IP packet, it needs to map
  44.    the packet's IP address to an IDPR Administrative Domain (AD) in
  45.    order to deliver the packet.  The initial prototype implementation of
  46.    IDPR used a configuration file to provide this mapping, but this is
  47.    clearly unacceptable for a full-scale deployment of IDPR.  As an
  48.    existing, well understood, (relatively) low-overhead distributed
  49.    database, the DNS is the obvious mechanism by which to distribute
  50.  
  51.  
  52.  
  53. Austein                  Expires 27 April 1994                  [Page 1]
  54.  
  55. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  56.  
  57.  
  58.    these mappings.
  59.  
  60.    Due to an unfortunate collision in use of the term "domain" by both
  61.    IDPR and the DNS, this note avoids unqualified use of the term
  62.    "domain."
  63.  
  64. 2. The AD RR type.
  65.  
  66.    We define one new DNS RR type, with symbolic name "AD" and numeric
  67.    value xxx.  This RR type is class-independent; the rest of this note
  68.    discusses IN class AD RRs, with the understanding that the mechanism
  69.    described here is not tied to IP addresses.  The RDATA portion of an
  70.    AD RR consists of two 32-bit integers, each representing an IDPR AD.
  71.    The two fields are the "home" AD associated with the address, and the
  72.    proxy AD associated with the address.  An AD which is acting as its
  73.    own proxy (the normal case) has the same value for these two fields.
  74.  
  75.    When written in a master zone file, these fields are written as
  76.    unsigned decimal integers; no characters other than the digits zero
  77.    through nine may appear in these fields.  The "proxy" field may be
  78.    omitted, in which case its value is the same as the "home" field.
  79.  
  80.    Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
  81.    space.  These RRs are used to map from an IP address to an IDPR AD.
  82.  
  83.    Since the IN-ADDR.ARPA portion of the DNS name space is (or should
  84.    be) already populated with PTR RRs mapping IP addresses to DNS names,
  85.    the DNS wildcard name mechanism will not generate AD RRs for IP that
  86.    have associated PTR RRs.  However, since not all IP addresses have
  87.    associated DNS names, it will probably be useful to add wildcard AD
  88.    RRs to master files where appropriate to insure that there is a
  89.    "default" AD associated with every IP address on a given IP network
  90.    or subnetwork.
  91.  
  92.    For purposes of discussion, assume that Miskatonic University is in
  93.    Administrative Domain 42, while Engulf & Devour, Inc., is in
  94.    Administrative Domains 666 and 17; Engulf & Devour recently purchased
  95.    Liver Donors Ltd., in order to use their Policy Gateway as a proxy
  96.    for Engulf & Devour's corporate network.  All IP addresses within
  97.    Miskatonic University are advertised as being Miskatonic's
  98.    Administrative Domain, while Engulf & Devour choses to publish
  99.    Administrative Domain information only for specific hosts.  The
  100.    following RRs might appear in the DNS:
  101.  
  102.            Loki.Miskatonic.EDU.   IN A 1.1.1.5
  103.            Thor.Miskatonic.EDU.   IN A 1.1.1.6
  104.            Liver-Donors.EaD.COM.  IN A 2.2.2.7
  105.            HQ.EaD.COM.            IN A 3.3.3.8
  106.  
  107.  
  108.  
  109. Austein                  Expires 27 April 1994                  [Page 2]
  110.  
  111. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  112.  
  113.  
  114.            5.1.1.1.IN-ADDR.ARPA.  IN PTR   Loki.Miskatonic.EDU.
  115.            5.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  116.            6.1.1.1.IN-ADDR.ARPA.  IN PTR   Thor.Miskatonic.EDU.
  117.            6.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  118.            *.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  119.            7.2.2.2.IN-ADDR.ARPA.  IN PTR   Liver-Donors.EaD.COM.
  120.            7.2.2.2.IN-ADDR.ARPA.  IN AD    666 666
  121.            8.3.3.3.IN-ADDR.ARPA.  IN PTR   HQ.EaD.COM.
  122.            8.3.3.3.IN-ADDR.ARPA.  IN AD    17  666
  123.  
  124. 3. Use of the AD RR type.
  125.  
  126.    In the initial deployment of of IDPR, we believe that only IDPR
  127.    Policy Gateways will need to know about IDPR ADs.  Thus, only Policy
  128.    Gateways will need to obtain and use AD RRs.  In the long run it may
  129.    be beneficial for hosts to obtain this data as well, but it is not
  130.    necessary that they do so in order for IDPR to work correctly.
  131.  
  132. 4. Bootstrapping the Policy Gateways
  133.  
  134.    Since a Policy Gateway needs an AD before it can forward a packet,
  135.    the AD associated with the IP addresses of each of the Policy
  136.    Gateway's default DNS name servers needs to be part of the Policy
  137.    Gateway's configuration.  Ie, there is a bootstrapping problem here,
  138.    because we can't use the DNS to obtain the ADs we need in order to
  139.    talk to the DNS.  Note that the Policy Gateway's default DNS name
  140.    servers are not necessarily the root DNS name servers; indeed, clever
  141.    use of centralized DNS caches by a community of Policy Gateways will
  142.    help decrease the load IDPR will add to the existing DNS system.
  143.    Ultimately, however, this question reduces to the question of how the
  144.    Policy Gateways reach the DNS root servers.
  145.  
  146. 5. Glue RRs
  147.  
  148.    Since in some cases the authoritative nameservers for a particular AD
  149.    RR may be within the AD itself, it may be necessary to insert "glue"
  150.    AD RRs into some zones in the IN-ADDR.ARPA tree.  These fill the same
  151.    role as the glue A RRs already in use to solve the analogous problem
  152.    with finding the IP address of a name server.
  153.  
  154. 6. Security Considerations
  155.  
  156.    Security considerations ane not discussed in this memo.
  157.  
  158. 7. Acknowledgments
  159.  
  160.    Most of the ideas in this document were derived from email
  161.    conversations with Martha Steenstrup and Robert Woodburn, without
  162.  
  163.  
  164.  
  165. Austein                  Expires 27 April 1994                  [Page 3]
  166.  
  167. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  168.  
  169.  
  170.    whose help the author would still be completely clueless about IDPR
  171.    and its requirements.  Thanks also to Mike Patton for catching a
  172.    serious error in the way that an earlier draft of this document
  173.    proposed to use DNS wildcard names.
  174.  
  175. 8. References
  176.  
  177.    [1]  Steenstrup, M., "An Architecture for Inter-Domain Policy
  178.         Routing", RFC 1478, June 1993.
  179.  
  180.    [2]  Mockapetris, P., "Domain names - concepts and facilities", RFC
  181.         1034, November 1987.
  182.  
  183.    [3]  Mockapetris, P., "Domain names - implementation and
  184.         specification", RFC 1035, November 1987.
  185.  
  186.    [4]  Lottor, M., "Domain administrators operations guide", RFC 1033,
  187.         November 1987.
  188.  
  189. 9. Author's address:
  190.  
  191.       Rob Austein
  192.       Epilogue Technology Corporation
  193.       268 Main Street, Suite 283
  194.       North Reading, MA 01864
  195.       USA
  196.  
  197.       Phone: +1-617-942-0915
  198.       EMail: sra@epilogue.com
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Austein                  Expires 27 April 1994                  [Page 4]
  222.  
  223.